Capabilities to achieve cooperation in processing via networks have become commonplace even in office devices and home devices. In order to achieve such cooperation in processing, the devices need to have status information indicating their status, state, etc., and profile information indicating their capability, ability, specification, etc., and to exchange the information with each other in a common form of representation using a common communication means. In order to realize such advanced network processing, in device-incorporated software, an approach for managing the software by separating it into a plurality of components, such as one or more pieces of application software, middleware and firmware, is becoming popular.
Application software realizes the main capability of the device. Middleware collectively provides common capabilities within the device, as typified by network control, corresponding to a request from the application software. Firmware achieves control of a hardware capability.
An example of middleware for collectively providing common capabilities within the device as typified by network control is UPnP (Universal Plug and Play). There also exist other protocols, such as Jini, Jxta, and the like, which have similar purposes and capabilities.
UPnP is designed as communication software which requires relatively advanced processing such as HTTP and XML technologies, and it is not easy to always develop and install this for each device individually. Furthermore, if a device for a specific application, such as a printer or a VCR, is developed, for example, it is needless to say that the main capability of the device, a capability specific to the device such as a printing unit or a recording/reproducing capability, should also be developed. Thus, the software for common communication capabilities such as UPnP is generally composed as a separable component in the form of middleware as described above.
In this way, as demand for high-capability devices grows, the middleware in the device-incorporated software is also becoming more advanced and complicated, and computing resources and computing abilities required by the middleware are also increasing accordingly.
Additionally, incorporating higher capabilities into a device with a communication capability has created demand to further incorporate a plurality of such middleware components. For example, in order to realize a device having a communication capability to dynamically support both UPnP and Jini, the device may incorporate two types of corresponding middleware components. Thus, if it is desired that different types of protocols are supported, a plurality of middleware components corresponding to respective protocols would be incorporated within the device.
In this way, incorporating a plurality of middleware components, which are becoming bloated as the device is becoming more advanced and complicated, is a major constraint for a device having a relatively limited computation capability, and how to manage this in an efficient manner becomes a major problem.
In a technique described in EP0511143, an interface object for representing the ability of a software module is sent to a server, and is sent back after being updated at the server. In this case, a module A registers its desired capability with the server first, and then checks to see if the interface object of a module B matches it through the server. By doing this, a determination can be made as to whether or not the module B is needed for the module A.
This technique assumes the presence of a server with which the capabilities of respective software modules are registered and which can be used on a permanent basis. Therefore, this technique is difficult to apply when assuming devices that are used in, for example, a network temporarily established at home, outdoors, or elsewhere. Also, because the technique can only determine whether the module B meets a previously desired condition, it cannot make a determination as to different conditions of a plurality of devices in combination. In other words, the object of the technique of EP0511143 still remains no more than providing a means for detecting what can be done, in a case where a software module is replaced in a system.
Thus, in the prior art optimization can be achieved within a single device. However, they still cannot optimize middleware incorporated in a device having a communication capability, which needs to be optimized in connection with a plurality of devices.